Les langages de programmations, de quelques paradigmes qu'ils soient (bien qu'un peu moins pour le paradigme logique), sont basés sur le concept de liste d'instructions exécutées à la suite par la machine. La machine exécutant ce code est une machine à état, mais le programme n'est pas formellement pensé comme tel.
Les machines à état semblent pourtant un bon outil pour la programmation des logiciels que nous avons l'habitude de développer : facile à dessiner sur papier, permettant un découpage clair du fonctionnement de l'application.
Sans compter qu'une machine à état se patche plus facilement qu'un code classique où l'effet spaghetti peut vite impliquer des effets indésirables.
Les designers de Qt l'ont bien compris en permettant de définir des machines à état pour décrire le comportement du contrôleur.
C'est pourquoi certains se sont demandés si la programmation en machine à état ne devrait pas être plus pratiquée et aimée des programmeurs. C'est, par exemple, ce que se demande Willem van Bergen, carrément enthousiaste.
Celui-ci pense que c'est le stockage de l'historique qui est essentiel.
Plus circonspect, Alan Skorkin étudie la problématique de reprise de code, afin de comparer les approches, pour conclure que si les machines à états ne sont pas la panacée, elles sont très intéressantes si on conçoit le code avec.
Un très intéressant débat est né de cette polémique sur Hacker News.